Databases are repositories of information that are used in every sector of the economy to provide access to information. There are numerous kinds of databases, many different organizations of the data they contain, many different ways in which that the data can be indexed and retrieved, and many different data models for storing and retrieving the information.
Part of the reason for the wide and growing use of databases is that databases can be accessed in many ways to support many different operations. Application programming interfaces (APIs) have been designed to enable substantially any program to access a database during execution. As well, worldwide web browsers can access databases using active server pages, etc. The combined effect of the numerous and growing different mechanisms for accessing databases is a substantial increase in demand for databases. However, a plurality of interface types are required because of the many and growing number of diverse access mechanisms and corresponding programming models, protocols, data formats, etc.
Structured query language (SQL) is an example of an open standard for permitting access to different databases. While SQL provides a framework for database transactions, a number of implementations, protocol drivers, and communications protocols may be used to instantiate SQL requests. Furthermore other competing programming models, languages, protocols, and implementations may have respective merits for providing simplicity, efficiency, or other desirable qualities in respective computing environments. Importantly, new access techniques are being developed. Consequently, database access systems generally have to be rewritten to permit new functionality for these new access techniques. Rewriting database access systems is very expensive and time consuming.
While methods for incorporating multiple protocol and programming model layers in a database system are known, these are generally inefficient. One solution is to provide a respective code path for each pair of receive and transmit layers so that a particular type of interface is effected using the respective code paths. While this solution may facilitate addition of an interface type, this multifaceted approach contributes significantly to the complexity of the programs used to enable these interfaces.
Furthermore, whenever one aspect of one of the receive or transmit layers has to be upgraded, all of the code paths have to be independently upgraded, and addition of one type of receive or transmit layer, hereinafter respectively referred to as the source and target layers, requires the addition of code paths for each of the source and target layer pairs. In accordance with another solution, a neutral internal language is used, and all source layers are translated into the neutral language, which is then translated into respective target layer formats.
While this is an improvement over the multiple code paths, large amounts of memory are consumed because all of the data has to be stored multiple times to format and reformat the data. The memory provision becomes expensive in high volume database servers and other computers that perform database transaction processing.
Therefore, there exists a need for an apparatus and method for enabling more efficient handling of database transaction processing that permits independence between source and target layers but does not require duplication of transaction data during processing. The need for such a system has heretofore remained unsatisfied.